wasi-http: validate the Host header used as incoming request authority - #15023

When an incoming request's target has no authority (the usual origin-form GET /path), incoming-request.authority falls back to the Host header. The p2 path in new_incoming_request copied that header string verbatim, so a client can hand the guest an "authority" that is not one at all. With wasmtime serve and a p2 proxy component, these Host values all come through unchanged today:

Host: evil.com#.example.com    -> authority "evil.com#.example.com"
Host: evil.com/x?.example.com  -> authority "evil.com/x?.example.com"
Host: user@evil.com            -> authority "user@evil.com"
Host: example.com:abc          -> authority "example.com:abc"
Host: a b                      -> authority "a b"

A guest that checks the authority with something like ends_with(".example.com") and then builds http://{authority}/... for a redirect or an absolute link ends up pointing at evil.com. The p3 path in Prepared::new already parses the header with http::uri::Authority, which rejects the first three of these but still accepts userinfo and a non-numeric port.

Both incoming paths now use the crate's existing parse_authority, which already enforces the uri-host [":" port] grammar for outgoing authorities. For p2 an invalid Host gets a 400, as RFC 9112 section 3.2 requires and as p2 already does for a missing Host. p3 keeps its current behavior of leaving the authority unset when the header doesn't parse. Requests whose target carries an authority are unchanged.

I added a unit test next to set_status_code_range that checks valid hosts (including [::1]:443) still come through and the values above get a 400. It fails without the fix and passes with it. cargo test -p wasmtime-wasi-http (unit, integration and doc tests), cargo clippy -p wasmtime-wasi-http --all-targets and cargo fmt --all -- --check all pass locally.